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Abstract 


This document provides principles for the operation of Internet Assigned Numbers Authority 
(IANA) registries. 


Status of This Memo 


This document is not an Internet Standards Track specification; it is published for informational 
purposes. 


This document is a product of the Internet Architecture Board (IAB) and represents information 
that the IAB has deemed valuable to provide for permanent record. It represents the consensus 
of the Internet Architecture Board (IAB). Documents approved for publication by the IAB are not 
candidates for any level of Internet Standard; see Section 2 of RFC 7841. 


Information about the current status of this document, any errata, and how to provide feedback 
on it may be obtained at https://www.rfc-editor.org/info/rfc8720. 


Copyright Notice 


Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights 
reserved. 


This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF 
Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this 
document. Please review these documents carefully, as they describe your rights and restrictions 
with respect to this document. 
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1. Introduction 


The Internet Engineering Task Force (IETF) and its predecessors have traditionally separated the 
publication of protocol specifications in immutable Request for Comments (RFCs) and the 
registries containing protocol parameters. Traditionally, the registries are maintained by a set of 
functions known collectively as the Internet Assigned Numbers Authority (IANA). Dating back to 
the earliest days of the Internet, specification publication and the registry operations were tightly 
coupled: Jon Postel of the Information Sciences Institute (ISI) of the University of Southern 
California (USC) was responsible for both RFC publication and IANA registry operation. This tight 
coupling had advantages, but it was never a requirement. Indeed, today, the RFC Editor and 
IANA registry operation are provided by different entities. 


Internet registries are critical to the operation of the Internet because they provide a definitive 
record of the value and meaning of identifiers that protocols use when communicating with each 
other. Almost every Internet protocol makes use of registries in some form. At the time of 
writing, the IANA maintains more than two thousand protocol parameter registries. 
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Internet registries hold protocol identifiers consisting of constants and other well-known values 
used by Internet protocols. These values can be numbers, strings, addresses, and so on. They are 
uniquely assigned for one particular purpose or use. Identifiers can be maintained in a central 
list (such as a list of cryptographic algorithms), or they can be hierarchically allocated and 
assigned by separate entities at different points in the hierarchy (such as IP addresses and 
domain names). To maximize trust and usefulness of the IANA registries, the principles in this 
document should be taken into consideration for centralized registries as well as hierarchically 
delegated registries. In hierarchically delegated registries, entries nearest to top level have broad 
scope, but lower-level entries have narrow scope. The Internet Architecture Board (IAB) will 
encourage support for these principles in all delegations of Internet identifiers. 


The registry system is built on trust and mutual cooperation. The use of the registries is 
voluntary and is not enforced by mandates or certification policies. While the use of registries is 
voluntary, it is noted that the success of the Internet creates enormous pressure to use Internet 
protocols and the identifier registries associated with them. 


This document provides principles for the operation of IANA registries, ensuring that protocol 
identifiers have consistent meanings and interpretations across all implementations and 
deployments, thus providing the necessary trust in the IANA registries. 


2. Principles for the Operation of IANA Registries 


The following key principles underscore the successful functioning of the IANA registries, and 
they provide a foundation for trust in those registries: 


Ensure Uniqueness: 
The same protocol identifier must not be used for more than one purpose. 


Stable: 
Protocol identifier assignment must be lasting. 


Predictable: 
The process for making assignments must not include unexpected steps. 


Public: 
The protocol identifiers must be made available in well-known locations in a manner that 
makes them freely available to everyone. 


Open: 
The process that sets the policy for protocol identifier assignment and registration must be 
open to all interested parties. 


Transparent: 
The protocol registries and their associated policies should be developed in a transparent 
manner. 


Accountable: 
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Registry policy development and registry operations need to be accountable to the affected 
community. 


3. Discussion 


The principles discussed in Section 2 provide trust and confidence in the IANA registries. This 
section expands on these principles. 


3.1. Ensuring Uniqueness, Stability, and Predictability 


Protocol identifier assignment and registration must be unique, stable, and predictable. 
Developers, vendors, customers, and users depend on the registries for unique protocol 
identifiers that are assigned in a stable and predictable manner. 


A protocol identifier may only be reassigned for a different purpose after due consideration of 
the impact of such a reassignment and, if possible, with the consent of the original assignee. 


Recognizing that some assignments involve judgment, such as those involving a designated 
expert [RFC8126], a predictable process does not require completion in a predetermined number 
of days. Rather, it means that no unexpected steps are introduced in the process of making an 
assignment. 


3.2. Public 


Once assigned, the protocol identifiers must be made available in a manner that makes them 
freely available to everyone without restrictions. The use of a consistent publication location 
builds confidence in the registry. This does not mean that the publication location can never 
change, but it does mean that it must change infrequently and only after adequate prior notice. 


3.3. Open and Transparent 


The process that sets the policy for protocol identifier assignment and registration must be open 
to all interested parties and must operate in a transparent manner. 


When a registry is established, a policy is set for the addition of new entries and the updating of 
existing entries. While making additions and modifications, the registry operator may expose 
instances where policies lack clarity. When this occurs, the registry operator should provide 
helpful feedback to allow those policies to be improved. In addition, the registry operator not 
being involved in establishing registry policy avoids the risks associated with (perceptions of) 
favoritism and unfairness. 


Recognizing that some assignments involve judgment, such as those involving a designated 
expert [RFC8126], the recommendations by designated experts must be visible to the public to 
the maximum extent possible and subject to challenge or appeal. 
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3.4. Accountable 


The process that sets the policy for IANA registries and the operation of the registries must be 
accountable to the parties that rely on the protocol identifiers. Oversight is needed to ensure 
these are properly serving the affected community. 


In practice, accountability mechanisms for the registry operator may be defined by a contract, 
memoranda of understanding, or service level agreements (SLAs). An oversight body uses these 
mechanisms to ensure that the registry operator is meeting the needs of the affected community. 
The oversight body is held accountable to the affected community by vastly different 
mechanisms -- for instance, recall and appeal processes. 


For protocol parameters [RFC6220], the general oversight of the IANA function is performed by 
the IAB as a chartered responsibility from [RFC2850]. In addition, the IETF Administration 
Limited Liability Company (IETF LLC), as part of the IETF Administrative Support Activity (IASA), 
is responsible for IETF administrative and financial matters [RFC8711]. In that role, the IETF LLC 
maintains an SLA with the current registry operator, the Internet Corporation for Assigned 
Names and Numbers (ICANN), thereby specifying the operational requirements with respect to 
the coordination, maintenance, and publication of the protocol parameter registries. Both the 
IAB and the Board of the IETF LLC are accountable to the larger Internet community and are 
being held accountable through the IETF NomCom process [RFC8713]. 


For the Internet Number Registries [RFC7249], oversight is performed by the Regional Internet 
Registries (RIRs) as described RFC 7020 [RFC7020]. The RIRs are member-based organizations, 
and they are accountable to the affected community by elected governance boards. Furthermore, 
per agreement between the RIRs and ICANN, the policy development for the global IANA number 
registries is coordinated by a community-elected number council and subject to process review 
before ratification by the ICANN Board of Trustees [ASOMOU]. 


4. Security Considerations 


Internet registries are critical to elements of Internet security. The principles described in this 
document are necessary for the Internet community to place trust in the IANA registries. 


5. Changes since RFC 7500 


Section 3.4 has been updated to align with the restructuring of the IETF Administrative Support 
Activity (IASA). Under the new structure, the IETF LLC maintains an SLA with the protocol 
parameter registry operator. Under the old structure, the SLA was maintained by the IETF 
Administrative Oversight Committee (IAOC). 
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